home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The CICA Windows Explosion!
/
The CICA Windows Explosion! - Disc 2.iso
/
nt
/
ntkb.zip
/
NTKB.EXE
/
Q101
/
5
/
03.TXT
< prev
next >
Wrap
Text File
|
1993-11-16
|
4KB
|
94 lines
DOCUMENT:Q101503 04-NOV-1993 [W_NT]
TITLE :INF: Reasons Windows NT Device Drivers Contain "Trusted" Code
PRODUCT :Windows NT
PROD/VER:3.10
OPER/SYS:WINDOWS
KEYWORDS:
--------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows NT operating system, version 3.1
- Microsoft Windows NT Advanced Server, version 3.1
--------------------------------------------------------------------
In the process of designing an operating system I/O subsystem, there
are many different methods to combine device drivers and file systems.
Each design possibility has its own advantages and disadvantages,
including those that affect ease of debugging, system robustness, and
performance.
The Windows NT I/O system was designed such that it forces the system
to trust device drivers. There are three primary reasons for this
restriction, as follows:
Drivers Run In Kernel Mode
--------------------------
Any kernel-mode code can perform any operation in the system. For
example, a driver can load a pointer with the base address of the
System Virtual Address space and go into a loop, writing zeros over
the executive system, the nonpaged memory pool, or anywhere else in
memory.
The alternative to running drivers in kernel mode involves running
drivers in user mode. A bug in a user-mode driver affects only the
driver which can ease the process of debugging the driver. These
advantages are countered by the disadvantage that a user-mode driver
requires its own virtual address space and must be its own process.
Because the time required to switch contexts into a user-mode driver
seriously degrades performance, kernel mode was chosen instead.
No Argument Checking
--------------------
Because a driver runs in kernel mode and have unfettered access to the
system, the design of the system assumes that a driver does not
perform any unintended operations. In other words, they, like the
executive system, have been thoroughly debugged and are virtually bug
free. If this is true, then it follows that they do not specify
incorrect parameters in calls to executive functions. For example, a
driver is assumed not to attempt to free an MDL that has a NULL
address. Because the system does not check each argument for
driver-level function calls as the system does for applications, it
runs faster and has better response time.
Driver Directory Protection
---------------------------
In a fully-secure system, the system administrator configures the
system so all disk partitions run the Windows NT file system (NTFS).
This allows the administrator to place an access control list (ACL) on
the directory from which the system loads drivers to prevent
unauthorized access to the directory. Doing so eliminates the
possibility that a user can load a "Trojan Horse" driver. Of course, a
secure system uses the same mechanism to protect the portion of the
Registry that lists the drivers to load and their locations.
As the text above indicates, the primary reasons to make drivers
trusted involve performance. Drivers run in kernel mode, in the
caller's context or in the context of an interrupt or DPC, which
eliminates the large overhead a context switch requires. The system
does not check the arguments they pass to executive functions for
performance reasons as well. Finally, if you configure your system
correctly, it is protected from loading a bad driver.
Additional reference words: 3.10
KBCategory:
KBSubcategory: DEVDRVR
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1993.